extract packaging changes from 4.4.6-1+rpi2 (fb687a494fd8d713b0741c597a37634daf9965b9)

extract packaging changes from 4.4.6-1+rpi1 (e33ea30e7dd76c932c09abaac500661c4e9238cf)

Merge linux (4.4.6-1) import into refs/heads/workingbranch

netfilter: x_tables: check for size overflow

Ben Hawkes says:
 integer overflow in xt_alloc_table_info, which on 32-bit systems can
 lead to small structure allocation and a copy_from_user based heap
 corruption.

Reported-by: Ben Hawkes <hawkes@google.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name netfilter-x_tables-check-for-size-overflow.patch

x86/mm/pat: Fix boot crash when 1GB pages are not supported by cpu

Scott reports that with the new separate EFI page tables he's seeing
the following error on boot, caused by setting reserved bits in the
page table structures (fault code is PF_RSVD | PF_PROT),

  swapper/0: Corrupted page table at address 17b102020
  PGD 17b0e5063 PUD 1400000e3
  Bad pagetable: 0009 [#1] SMP

On first inspection the PUD is using a 1GB page size (_PAGE_PSE) and
looks fine but that's only true if support for 1GB PUD pages
("pdpe1gb") is present in the cpu.

Scott's Intel Celeron N2820 does not have that feature and so the
_PAGE_PSE bit is reserved. Fix this issue by making the 1GB mapping
code in conditional on "cpu_has_gbpages".

This issue didn't come up in the past because the required mapping for
the faulting address (0x17b102020) will already have been setup by the
kernel in early boot before we got to efi_map_regions(), but we no
longer use the standard kernel page tables during EFI calls.

Reported-by: Scott Ashcroft <scott.ashcroft@talk21.com>
Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Raphael Hertzog <hertzog@debian.org>
Cc: Roger Shimizu <rogershimizu@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name x86-mm-pat-fix-boot-crash-when-1gb-pages-are-not-supported.patch

x86/efi: Fix boot crash by always mapping boot service regions into new EFI page tables

Some machines have EFI regions in page zero (physical address
0x00000000) and historically that region has been added to the e820
map via trim_bios_range(), and ultimately mapped into the kernel page
tables. It was not mapped via efi_map_regions() as one would expect.

Alexis reports that with the new separate EFI page tables some boot
services regions, such as page zero, are not mapped. This triggers an
oops during the SetVirtualAddressMap() runtime call.

For the EFI boot services quirk on x86 we need to memblock_reserve()
boot services regions until after SetVirtualAddressMap(). Doing that
while respecting the ownership of regions that may have already been
reserved by the kernel was the motivation behind this commit:

  7d68dc3f1003 ("x86, efi: Do not reserve boot services regions within reserved areas")

That patch was merged at a time when the EFI runtime virtual mappings
were inserted into the kernel page tables as described above, and the
trick of setting ->numpages (and hence the region size) to zero to
track regions that should not be freed in efi_free_boot_services()
meant that we never mapped those regions in efi_map_regions(). Instead
we were relying solely on the existing kernel mappings.

Now that we have separate page tables we need to make sure the EFI
boot services regions are mapped correctly, even if someone else has
already called memblock_reserve(). Instead of stashing a tag in
->numpages, set the EFI_MEMORY_RUNTIME bit of ->attribute. Since it
generally makes no sense to mark a boot services region as required at
runtime, it's pretty much guaranteed the firmware will not have
already set this bit.

For the record, the specific circumstances under which Alexis
triggered this bug was that an EFI runtime driver on his machine was
responding to the EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE event during
SetVirtualAddressMap().

The event handler for this driver looks like this,

  sub rsp,0x28
  lea rdx,[rip+0x2445] # 0xaa948720
  mov ecx,0x4
  call func_aa9447c0  ; call to ConvertPointer(4, & 0xaa948720)
  mov r11,QWORD PTR [rip+0x2434] # 0xaa948720
  xor eax,eax
  mov BYTE PTR [r11+0x1],0x1
  add rsp,0x28
  ret

Which is pretty typical code for an EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE
handler. The "mov r11, QWORD PTR [rip+0x2424]" was the faulting
instruction because ConvertPointer() was being called to convert the
address 0x0000000000000000, which when converted is left unchanged and
remains 0x0000000000000000.

The output of the oops trace gave the impression of a standard NULL
pointer dereference bug, but because we're accessing physical
addresses during ConvertPointer(), it wasn't. EFI boot services code
is stored at that address on Alexis' machine.

Reported-by: Alexis Murzeau <amurzeau@gmail.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Raphael Hertzog <hertzog@debian.org>
Cc: Roger Shimizu <rogershimizu@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1457695163-29632-2-git-send-email-matt@codeblueprint.co.uk
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815125
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name x86-efi-fix-boot-crash-by-always-mapping-boot-servic.patch

module: Fix ABI change in 4.4.5

Move the new kallsyms fields in struct module to the end and hide
them from genksyms.  Restore the old fields but leave them zeroed -
nothing outside the module loader and /proc/kallsyms implementation
should be, or appears to be, using them.

Gbp-Pq: Topic debian
Gbp-Pq: Name module-fix-abi-change-in-4.4.5.patch

Revert "libata: Align ata_device's id on a cacheline"

This reverts commit cea2cbff57c5b65375adb6fe65612c10a7301327, which
was commit 4ee34ea3a12396f35b26d90a094c75db95080baa upstream.  It's a
real fix but we've lived with the problem for many years and it
doesn't seem worth breaking ABI to fix it right now.

Gbp-Pq: Topic debian
Gbp-Pq: Name revert-libata-align-ata_device-s-id-on-a-cacheline.patch

drm/i915: Fix oops caused by fbdev initialization failure

intelfb_create() is called once on driver initialization. If it fails,
ifbdev->helper.fbdev, ifbdev->fb or ifbdev->fb->obj may be NULL.

Further up in the call stack, intel_fbdev_initial_config() calls
intel_fbdev_fini() to tear down the ifbdev on failure. This calls
intel_fbdev_destroy() which dereferences ifbdev->fb. Fix the ensuing
oops.

Also check in these functions if ifbdev is not NULL to avoid oops:

i915_gem_framebuffer_info() is called on access to debugfs file
"i915_gem_framebuffer" and dereferences ifbdev, ifbdev->helper.fb
and ifbdev->helper.fb->obj.

intel_connector_add_to_fbdev() / intel_connector_remove_from_fbdev()
are called when registering / unregistering an mst connector and
dereference ifbdev.

v3: Drop additional null pointer checks in intel_fbdev_set_suspend(),
    intel_fbdev_output_poll_changed() and intel_fbdev_restore_mode()
    since they already check if ifbdev is not NULL, which is sufficient
    now that intel_fbdev_fini() is called on initialization failure.
    (Requested by Daniel Vetter <daniel.vetter@ffwll.ch>)

Signed-off-by: Lukas Wunner <lukas@wunner.de>
Link: http://patchwork.freedesktop.org/patch/msgid/d05f0edf121264a9d0adb8ca713fd8cc4ae068bf.1447938059.git.lukas@wunner.de
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name drm-i915-Fix-oops-caused-by-fbdev-initialization-fai.patch

ipv6: Fix ABI change in 4.4.4

Change ip6_route_output() back from a static inline wrapper to a proper
extern and exported function.

Gbp-Pq: Topic debian
Gbp-Pq: Name ipv6-fix-abi-change-in-4.4.4.patch

ipv4: Fix ABI change in 4.4.4

struct fib_nh_exception is always allocated and used in the ipv4 core,
which is built-in.  As the new field is at the end of the structure,
all we need to do is hide it from genksyms.

Gbp-Pq: Topic debian
Gbp-Pq: Name ipv4-fix-abi-change-in-4.4.4.patch

thermal: Fix ABI change in 4.4.4

struct thermal_zone_device is always allocated in thermal_core and the
new field is only used there.  So we can safely move it to the end of the
structure and hide it from genksyms.

Also hide the new #include, as if it could make an actual difference,
stupid genksyms...

Gbp-Pq: Topic debian
Gbp-Pq: Name thermal-fix-abi-change-in-4.4.4.patch

Revert "cgroup: make sure a parent css isn't offlined before its children"

This reverts commit 4cbd196324c05809338c7f118b6f374d3c2db7a0, which
was commit aa226ff4a1ce79f229c6b7a4c0a14e17fececd01 upstream.  It
seems to be a good fix but causes an unfixable ABI change as it
extends a structure that's embedded in other structures.

Gbp-Pq: Topic debian
Gbp-Pq: Name revert-cgroup-make-sure-a-parent-css-isn-t-offlined.patch

uas: Fix high-order alloc

Can you try building a kernel with the following line in drivers/usb/storage/uas.c :

         .can_queue = 65536,     /* Is there a limit on the _host_ ? */

(around line 815) Replaced with

         .can_queue = MAX_CMNDS,

That should help as MAX_CMNDS is 256, so claiming that we can queue more
is not helpful, and that likely is what is causing this quite high order alloc.

Reported-and-tested-by: Yves-Alexis Perez <corsac@corsac.net>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name uas-fix-high-order-alloc.patch

x86/efi-bgrt: Replace early_memremap() with memremap()

Môshe reported the following warning triggered on his machine since
commit 50a0cb565246 ("x86/efi-bgrt: Fix kernel panic when mapping BGRT
data"),

  [    0.026936] ------------[ cut here ]------------
  [    0.026941] WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:137 __early_ioremap+0x102/0x1bb()
  [    0.026941] Modules linked in:
  [    0.026944] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.0-rc1 #2
  [    0.026945] Hardware name: Dell Inc. XPS 13 9343/09K8G1, BIOS A05 07/14/2015
  [    0.026946]  0000000000000000 900f03d5a116524d ffffffff81c03e60 ffffffff813a3fff
  [    0.026948]  0000000000000000 ffffffff81c03e98 ffffffff810a0852 00000000d7b76000
  [    0.026949]  0000000000000000 0000000000000001 0000000000000001 000000000000017c
  [    0.026951] Call Trace:
  [    0.026955]  [<ffffffff813a3fff>] dump_stack+0x44/0x55
  [    0.026958]  [<ffffffff810a0852>] warn_slowpath_common+0x82/0xc0
  [    0.026959]  [<ffffffff810a099a>] warn_slowpath_null+0x1a/0x20
  [    0.026961]  [<ffffffff81d8c395>] __early_ioremap+0x102/0x1bb
  [    0.026962]  [<ffffffff81d8c602>] early_memremap+0x13/0x15
  [    0.026964]  [<ffffffff81d78361>] efi_bgrt_init+0x162/0x1ad
  [    0.026966]  [<ffffffff81d778ec>] efi_late_init+0x9/0xb
  [    0.026968]  [<ffffffff81d58ff5>] start_kernel+0x46f/0x49f
  [    0.026970]  [<ffffffff81d58120>] ? early_idt_handler_array+0x120/0x120
  [    0.026972]  [<ffffffff81d58339>] x86_64_start_reservations+0x2a/0x2c
  [    0.026974]  [<ffffffff81d58485>] x86_64_start_kernel+0x14a/0x16d
  [    0.026977] ---[ end trace f9b3812eb8e24c58 ]---
  [    0.026978] efi_bgrt: Ignoring BGRT: failed to map image memory

early_memremap() has an upper limit on the size of mapping it can
handle which is ~200KB. Clearly the BGRT image on Môshe's machine is
much larger than that.

There's actually no reason to restrict ourselves to using the early_*
version of memremap() - the ACPI BGRT driver is invoked late enough in
boot that we can use the standard version, with the benefit that the
late version allows mappings of arbitrary size.

Reported-by: Môshe van der Sterre <me@moshe.nl>
Tested-by: Môshe van der Sterre <me@moshe.nl>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Link: http://lkml.kernel.org/r/1450707172-12561-1-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name x86-efi-bgrt-replace-early_memremap-with-memremap.patch

x86/efi-bgrt: Fix kernel panic when mapping BGRT data

Starting with this commit 35eb8b81edd4 ("x86/efi: Build our own page
table structures") efi regions have a separate page directory called
"efi_pgd". In order to access any efi region we have to first shift %cr3
to this page table. In the bgrt code we are trying to copy bgrt_header
and image, but these regions fall under "EFI_BOOT_SERVICES_DATA"
and to access these regions we have to shift %cr3 to efi_pgd and not
doing so will cause page fault as shown below.

[    0.251599] Last level dTLB entries: 4KB 64, 2MB 0, 4MB 0, 1GB 4
[    0.259126] Freeing SMP alternatives memory: 32K (ffffffff8230e000 - ffffffff82316000)
[    0.271803] BUG: unable to handle kernel paging request at fffffffefce35002
[    0.279740] IP: [<ffffffff821bca49>] efi_bgrt_init+0x144/0x1fd
[    0.286383] PGD 300f067 PUD 0
[    0.289879] Oops: 0000 [#1] SMP
[    0.293566] Modules linked in:
[    0.297039] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.0-rc1-eywa-eywa-built-in-47041+ #2
[    0.306619] Hardware name: Intel Corporation Skylake Client platform/Skylake Y LPDDR3 RVP3, BIOS SKLSE2R1.R00.B104.B01.1511110114 11/11/2015
[    0.320925] task: ffffffff820134c0 ti: ffffffff82000000 task.ti: ffffffff82000000
[    0.329420] RIP: 0010:[<ffffffff821bca49>]  [<ffffffff821bca49>] efi_bgrt_init+0x144/0x1fd
[    0.338821] RSP: 0000:ffffffff82003f18  EFLAGS: 00010246
[    0.344852] RAX: fffffffefce35000 RBX: fffffffefce35000 RCX: fffffffefce2b000
[    0.352952] RDX: 000000008a82b000 RSI: ffffffff8235bb80 RDI: 000000008a835000
[    0.361050] RBP: ffffffff82003f30 R08: 000000008a865000 R09: ffffffffff202850
[    0.369149] R10: ffffffff811ad62f R11: 0000000000000000 R12: 0000000000000000
[    0.377248] R13: ffff88016dbaea40 R14: ffffffff822622c0 R15: ffffffff82003fb0
[    0.385348] FS:  0000000000000000(0000) GS:ffff88016d800000(0000) knlGS:0000000000000000
[    0.394533] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    0.401054] CR2: fffffffefce35002 CR3: 000000000300c000 CR4: 00000000003406f0
[    0.409153] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    0.417252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    0.425350] Stack:
[    0.427638]  ffffffffffffffff ffffffff82256900 ffff88016dbaea40 ffffffff82003f40
[    0.436086]  ffffffff821bbce0 ffffffff82003f88 ffffffff8219c0c2 0000000000000000
[    0.444533]  ffffffff8219ba4a ffffffff822622c0 0000000000083000 00000000ffffffff
[    0.452978] Call Trace:
[    0.455763]  [<ffffffff821bbce0>] efi_late_init+0x9/0xb
[    0.461697]  [<ffffffff8219c0c2>] start_kernel+0x463/0x47f
[    0.467928]  [<ffffffff8219ba4a>] ? set_init_arg+0x55/0x55
[    0.474159]  [<ffffffff8219b120>] ? early_idt_handler_array+0x120/0x120
[    0.481669]  [<ffffffff8219b5ee>] x86_64_start_reservations+0x2a/0x2c
[    0.488982]  [<ffffffff8219b72d>] x86_64_start_kernel+0x13d/0x14c
[    0.495897] Code: 00 41 b4 01 48 8b 78 28 e8 09 36 01 00 48 85 c0 48 89 c3 75 13 48 c7 c7 f8 ac d3 81 31 c0 e8 d7 3b fb fe e9 b5 00 00 00 45 84 e4 <44> 8b 6b 02 74 0d be 06 00 00 00 48 89 df e8 ae 34 0$
[    0.518151] RIP  [<ffffffff821bca49>] efi_bgrt_init+0x144/0x1fd
[    0.524888]  RSP <ffffffff82003f18>
[    0.528851] CR2: fffffffefce35002
[    0.532615] ---[ end trace 7b06521e6ebf2aea ]---
[    0.537852] Kernel panic - not syncing: Attempted to kill the idle task!

As said above one way to fix this bug is to shift %cr3 to efi_pgd but we
are not doing that way because it leaks inner details of how we switch
to EFI page tables into a new call site and it also adds duplicate code.
Instead, we remove the call to efi_lookup_mapped_addr() and always
perform early_mem*() instead of early_io*() because we want to remap RAM
regions and not I/O regions. We also delete efi_lookup_mapped_addr()
because we are no longer using it.

Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Reported-by: Wendy Wang <wendy.wang@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Ricardo Neri <ricardo.neri@intel.com>
Cc: Ravi Shankar <ravi.v.shankar@intel.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name x86-efi-bgrt-fix-kernel-panic-when-mapping-bgrt-data.patch

net: mv643xx_eth: fix packet corruption with TSO and tiny unaligned packets.

The code in txq_put_data() would use txq->tx_curr_desc to index the
tso_hdrs/tso_hdrs_dma buffers, for less than 8 bytes unaligned
fragments, which is already moved to the next descriptor at the
beginning of the function.

If that fragment was the last of the the skb, the next skb would use
that same space to place the ip headers, overwritting that small
fragment data.

Fixes: 91986fd3d335 (net: mv643xx_eth: Ensure proper data alignment in TSO TX path)
Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
Reviewed-by: Philipp Kirchhofer <philipp@familie-kirchhofer.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Gbp-Pq: Topic bugfix/arm
Gbp-Pq: Name net-mv643xx_eth-fix-packet-corruption-with-tso-and-t.patch

PCI: Set pci=nobios by default

CONFIG_PCI_GOBIOS results in physical addresses 640KB-1MB being mapped
W+X, which is undesirable for security reasons and will result in a
warning at boot now that we enable CONFIG_DEBUG_WX.

This can be overridden using the kernel parameter "pci=nobios", but we
want to disable W+X by default.  Disable PCI BIOS probing by default;
it can still be enabled using "pci=bios".

Gbp-Pq: Topic debian
Gbp-Pq: Name i386-686-pae-pci-set-pci-nobios-by-default.patch

x86/efi: Setup separate EFI page tables in kexec paths

The switch to using a new dedicated page table for EFI runtime
calls in commit commit 67a9108ed431 ("x86/efi: Build our own
page table structures") failed to take into account changes
required for the kexec code paths, which are unfortunately
duplicated in the EFI code.

Call the allocation and setup functions in
kexec_enter_virtual_mode() just like we do for
__efi_enter_virtual_mode() to avoid hitting NULL-pointer
dereferences when making EFI runtime calls.

At the very least, the call to efi_setup_page_tables() should
have existed for kexec before the following commit:

  67a9108ed431 ("x86/efi: Build our own page table structures")

Things just magically worked because we were actually using
the kernel's page tables that contained the required mappings.

Reported-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Tested-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1453385519-11477-1-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name x86-efi-setup-separate-efi-page-tables-in-kexec-path.patch

x86/efi: Build our own page table structures

With commit e1a58320a38d ("x86/mm: Warn on W^X mappings") all
users booting on 64-bit UEFI machines see the following warning,

  ------------[ cut here ]------------
  WARNING: CPU: 7 PID: 1 at arch/x86/mm/dump_pagetables.c:225 note_page+0x5dc/0x780()
  x86/mm: Found insecure W+X mapping at address ffff88000005f000/0xffff88000005f000
  ...
  x86/mm: Checked W+X mappings: FAILED, 165660 W+X pages found.
  ...

This is caused by mapping EFI regions with RWX permissions.
There isn't much we can do to restrict the permissions for these
regions due to the way the firmware toolchains mix code and
data, but we can at least isolate these mappings so that they do
not appear in the regular kernel page tables.

In commit d2f7cbe7b26a ("x86/efi: Runtime services virtual
mapping") we started using 'trampoline_pgd' to map the EFI
regions because there was an existing identity mapping there
which we use during the SetVirtualAddressMap() call and for
broken firmware that accesses those addresses.

But 'trampoline_pgd' shares some PGD entries with
'swapper_pg_dir' and does not provide the isolation we require.
Notably the virtual address for __START_KERNEL_map and
MODULES_START are mapped by the same PGD entry so we need to be
more careful when copying changes over in
efi_sync_low_kernel_mappings().

This patch doesn't go the full mile, we still want to share some
PGD entries with 'swapper_pg_dir'. Having completely separate
page tables brings its own issues such as synchronising new
mappings after memory hotplug and module loading. Sharing also
keeps memory usage down.

Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Reviewed-by: Borislav Petkov <bp@suse.de>
Acked-by: Borislav Petkov <bp@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Jones <davej@codemonkey.org.uk>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1448658575-17029-6-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name x86-efi-build-our-own-page-table-structures.patch

x86/efi: Hoist page table switching code into efi_call_virt()

This change is a prerequisite for pending patches that switch to
a dedicated EFI page table, instead of using 'trampoline_pgd'
which shares PGD entries with 'swapper_pg_dir'. The pending
patches make it impossible to dereference the runtime service
function pointer without first switching %cr3.

It's true that we now have duplicated switching code in
efi_call_virt() and efi_call_phys_{prolog,epilog}() but we are
sacrificing code duplication for a little more clarity and the
ease of writing the page table switching code in C instead of
asm.

Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Reviewed-by: Borislav Petkov <bp@suse.de>
Acked-by: Borislav Petkov <bp@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Jones <davej@codemonkey.org.uk>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1448658575-17029-5-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name x86-efi-hoist-page-table-switching-code-into-efi_cal.patch

x86/efi: Map RAM into the identity page table for mixed mode

We are relying on the pre-existing mappings in 'trampoline_pgd'
when accessing function arguments in the EFI mixed mode thunking
code.

Instead let's map memory explicitly so that things will continue
to work when we move to a separate page table in the future.

Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Reviewed-by: Borislav Petkov <bp@suse.de>
Acked-by: Borislav Petkov <bp@suse.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1448658575-17029-4-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name x86-efi-map-ram-into-the-identity-page-table-for-mix.patch

x86/mm/pat: Ensure cpa->pfn only contains page frame numbers

The x86 pageattr code is confused about the data that is stored
in cpa->pfn, sometimes it's treated as a page frame number,
sometimes it's treated as an unshifted physical address, and in
one place it's treated as a pte.

The result of this is that the mapping functions do not map the
intended physical address.

This isn't a problem in practice because most of the addresses
we're mapping in the EFI code paths are already mapped in
'trampoline_pgd' and so the pageattr mapping functions don't
actually do anything in this case. But when we move to using a
separate page table for the EFI runtime this will be an issue.

Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Reviewed-by: Borislav Petkov <bp@suse.de>
Acked-by: Borislav Petkov <bp@suse.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1448658575-17029-3-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name x86-mm-pat-ensure-cpa-pfn-only-contains-page-frame-n.patch

x86/mm: Page align the '_end' symbol to avoid pfn conversion bugs

Ingo noted that if we can guarantee _end is aligned to PAGE_SIZE
we can automatically avoid bugs along the lines of,

size = _end - _text >> PAGE_SHIFT

which is missing a call to PFN_ALIGN(). The EFI mixed mode
contains this bug, for example.

_text is already aligned to PAGE_SIZE through the use of
LOAD_PHYSICAL_ADDR, and the BSS and BRK sections are explicitly
aligned in the linker script, so it makes sense to align _end to
match.

Reported-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Acked-by: Borislav Petkov <bp@suse.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1448658575-17029-2-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name x86-mm-page-align-the-_end-symbol-to-avoid-pfn-conve.patch

pipe: limit the per-user amount of pages allocated in pipes

On no-so-small systems, it is possible for a single process to cause an
OOM condition by filling large pipes with data that are never read. A
typical process filling 4000 pipes with 1 MB of data will use 4 GB of
memory. On small systems it may be tricky to set the pipe max size to
prevent this from happening.

This patch makes it possible to enforce a per-user soft limit above
which new pipes will be limited to a single page, effectively limiting
them to 4 kB each, as well as a hard limit above which no new pipes may
be created for this user. This has the effect of protecting the system
against memory abuse without hurting other users, and still allowing
pipes to work correctly though with less data at once.

The limit are controlled by two new sysctls : pipe-user-pages-soft, and
pipe-user-pages-hard. Both may be disabled by setting them to zero. The
default soft limit allows the default number of FDs per process (1024)
to create pipes of the default size (64kB), thus reaching a limit of 64MB
before starting to create only smaller pipes. With 256 processes limited
to 1024 FDs each, this results in 1024*64kB + (256*1024 - 1024) * 4kB =
1084 MB of memory allocated for a user. The hard limit is disabled by
default to avoid breaking existing applications that make intensive use
of pipes (eg: for splicing).

Reported-by: socketpair@gmail.com
Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Mitigates: CVE-2013-4312 (Linux 2.0+)
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name pipe-limit-the-per-user-amount-of-pages-allocated-in.patch

ptrace: being capable wrt a process requires mapped uids/gids

ptrace_has_cap() checks whether the current process should be
treated as having a certain capability for ptrace checks
against another process. Until now, this was equivalent to
has_ns_capability(current, target_ns, CAP_SYS_PTRACE).

However, if a root-owned process wants to enter a user
namespace for some reason without knowing who owns it and
therefore can't change to the namespace owner's uid and gid
before entering, as soon as it has entered the namespace,
the namespace owner can attach to it via ptrace and thereby
gain access to its uid and gid.

While it is possible for the entering process to switch to
the uid of a claimed namespace owner before entering,
causing the attempt to enter to fail if the claimed uid is
wrong, this doesn't solve the problem of determining an
appropriate gid.

With this change, the entering process can first enter the
namespace and then safely inspect the namespace's
properties, e.g. through /proc/self/{uid_map,gid_map},
assuming that the namespace owner doesn't have access to
uid 0.
Changed in v2: The caller needs to be capable in the
namespace into which tcred's uids/gids can be mapped.

Signed-off-by: Jann Horn <jann@thejh.net>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name ptrace-being-capable-wrt-a-process-requires-mapped-uids-gids.patch

usbvision: fix crash on detecting device with invalid configuration

The usbvision driver crashes when a specially crafted usb device with invalid
number of interfaces or endpoints is detected. This fix adds checks that the
device has proper configuration expected by the driver.

Reported-by: Ralf Spenneberg <ralf@spenneberg.net>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name media-usbvision-fix-crash-on-detecting-device-with-i.patch

usbvision fix overflow of interfaces array

This fixes the crash reported in:
http://seclists.org/bugtraq/2015/Oct/35
The interface number needs a sanity check.

Signed-off-by: Oliver Neukum <oneukum@suse.com>
Cc: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name usbvision-fix-overflow-of-interfaces-array.patch

grsecurity: GRKERNSEC_PERF_HARDEN

The GRKERNSEC_PERF_HARDEN feature extracted from grsecurity.  Adds the
option to disable perf_event_open() entirely for unprivileged users.
This standalone version doesn't include making the variable read-only
(or renaming it).

Gbp-Pq: Topic features/all/grsecurity
Gbp-Pq: Name grkernsec_perf_harden.patch

grsecurity: Kconfig integration

Kconfig integration changes extracted from Grsecurity, with help
strings changed to make it clear that is not the real thing.

Subsequent patches will add to the empty menu.

Gbp-Pq: Topic features/all/grsecurity
Gbp-Pq: Name grsecurity-kconfig.patch

rt2x00: fix monitor mode regression

Since commit df1404650ccb ("mac80211: remove support for IFF_PROMISC")
monitor mode for rt2x00 has been made effectively useless because the
hardware filter is configured to drop packets whose intended recipient is
not the device, regardless of the presence of monitor mode interfaces.

This patch fixes this regression by adding explicit monitor mode support,
and by configuring the hardware filter accordingly.

Signed-off-by: Eli Cooper <elicooper@gmx.com>
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
[bwh: Backported to 4.3: adjust filenames]

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name rt2x00-fix-monitor-mode-regression.patch

rtsx_usb_ms: Use msleep_interruptible() in polling loop

rtsx_usb_ms creates a task that mostly sleeps, but tasks in
uninterruptible sleep still contribute to the load average (for
bug-compatibility with Unix).  A load average of ~1 on a system that
should be idle is somewhat alarming.

Change the sleep to be interruptible, but still ignore signals.

A better fix might be to replace this loop with a delayed work item.

References: https://bugs.debian.org/765717
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name rtsx_usb_ms-use-msleep_interruptible-in-polling-loop.patch

phy/marvell: disable 4-port phys

The Marvell PHY was originally disabled because it can cause networking
failures on some systems. According to Lennert Buytenhek this is because some
of the variants added did not share the same register layout. Since the known
cases are all 4-ports disable those variants (indicated by a 4 in the
penultimate position of the model name) until they can be audited for
correctness.

[bwh: Also #if-out the init functions for these PHYs to avoid
 compiler warnings]

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name disable-some-marvell-phys.patch

kbuild: Use -nostdinc in compile tests

Debian's gcc 4.8 pre-includes <stdc-predef.h> by default, which in
turn includes <bits/predefs.h>.  This fails when building a 64-bit
kernel and only 32-bit C library headers installed.

The -nostdinc option disables this, though it isn't explicitly
documented.  This option is already used when actually building
the kernel.

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name kbuild-use-nostdinc-in-compile-tests.patch

misc/bmp085: Enable building as a module

Commit 985087dbcb02 'misc: add support for bmp18x chips to the bmp085
driver' changed the BMP085 config symbol to a boolean.  I see no
reason why the shared code cannot be built as a module, so change it
back to tristate.

Cc: Eric Andersson <eric.andersson@unixphere.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name misc-bmp085-Enable-building-as-a-module.patch

ARM: dts: imx6q: clean up unused ipu2grp

The pinctrl group ipu2grp is a leftover from the previous iomuxc DT
cleanup.  It's not used by anyone now.  More importantly, it's getting
in the way of saving the unnecessary pinfunc container node from the
board dts files that include imx6q.dtsi.

Let's clean it up.

Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Tested-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Gbp-Pq: Topic features/arm/novena
Gbp-Pq: Name ARM-dts-imx6q-clean-up-unused-ipu2grp.patch

ARM: dts: imx6q: add Novena board

Novena is an open-hardware laptop/desktop/bare board.

See http://www.kosagi.com/w/index.php?title=Novena_Main_Page

Signed-off-by: Sean Cross <xobs@kosagi.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Gbp-Pq: Topic features/arm/novena
Gbp-Pq: Name ARM-dts-imx6q-add-Novena-board.patch

ARM: dts: orion5x: add device tree for buffalo linkstation ls-gl

Add dts file to support Buffalo Linkstation LS-GL
(a.k.a Buffalo Linkstation Pro/Live), which is marvell orion5x based
3.5" HDD NAS.

Product info:
  - (JPN) http://buffalo.jp/products/catalog/item/l/ls-gl/
  - (ENG) http://www.buffalotech.com/products/network-storage/linkstation/linkstation-pro

This device tree is based on the board file:
  arch/arm/mach-orion5x/kurobox_pro-setup.c
However, that board file also support Kurobox Pro, which is not supported by
device tree yet. So the board file is not removed.

Signed-off-by: Roger Shimizu <rogershimizu@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gbp-Pq: Topic features/arm/device-tree
Gbp-Pq: Name ARM-dts-orion5x-add-for-buffalo-linkstation-ls-gl.patch

ARM: dts: orion5x: split linkstation lswtgl into common and device parts

In order to support more linkstation devices, common part of current
.dts file goes into .dtsi file. Some .dtsi start with "mvebu-" prefix
because other kirkwood based linkstation devices are similar, and
will be migrated to use these .dtsi some time later.
  - orion5x-linkstation.dtsi
  - mvebu-linkstation-fan.dtsi
  - mvebu-linkstation-gpio-simple.dtsi
while all rest part remains in device specific .dts file:
  - orion5x-linkstation-lswtgl.dts

Signed-off-by: Roger Shimizu <rogershimizu@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gbp-Pq: Topic features/arm/device-tree
Gbp-Pq: Name ARM-dts-orion5x-split-linkstation-lswtgl-into-common-and-.patch

ARM: dts: kirkwood: add device tree for buffalo linkstation ls-qvl

Add dts file to support Buffalo Linkstation LS-QVL,
which is marvell kirkwood based 4-bay 3.5" HDD NAS.
Product info:
  - (JPN) http://buffalo.jp/product/hdd/network/ls-qvl_r5/
  - (ENG) http://www.buffalotech.com/products/network-storage/home-and-small-office/linkstation-pro-quad

Signed-off-by: Mario Lange <mario_lange@gmx.net>
Signed-off-by: Roger Shimizu <rogershimizu@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gbp-Pq: Topic features/arm/device-tree
Gbp-Pq: Name ARM-dts-kirkwood-add-for-buffalo-linkstation-ls-qvl.patch

ARM: dts: kirkwood: split lswvl dts to linkstation lsvl and lswvl

LS-WVL/VL are both kirkwood-6282 based NAS devices, which share
many MPP pins. However they are slightly different:
  - LS-WVL is 2-Bay NAS, and LS-VL is only 1-Bay.
  - There're two red LED indicator on LS-WVL to show when HDD fails,
    which is similar to LS-WXL, but there's no such on LS-VL.

So after the split, common part goes into .dtsi file:
  - kirkwood-linkstation-6282.dtsi
while all rest part goes into device specific .dts file:
  - kirkwood-linkstation-lsvl.dts
  - kirkwood-linkstation-lswvl.dts

Signed-off-by: Roger Shimizu <rogershimizu@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gbp-Pq: Topic features/arm/device-tree
Gbp-Pq: Name ARM-dts-kirkwood-split-lswvl-dts-to-linkstation-lsvl-and-.patch

ARM: dts: kirkwood: split lswxl dts to linkstation lswsxl and lswxl

LS-WXL/WSXL are both kirkwood-6281 based 2-Bay NAS devices, which share
many MPP pins. However they are slightly different:
  - There're two red LED indicator on LS-WXL to show when HDD fails,
    but there's no such on LS-WSXL.
  - There's 4-level speed adjustable FAN on LS-WXL, but not LS-WSXL.

So after the split, common part goes into .dtsi file:
  - kirkwood-linkstation.dtsi
  - kirkwood-linkstation-duo-6281.dtsi
while all rest part goes into device specific .dts file:
  - kirkwood-linkstation-lswsxl.dts
  - kirkwood-linkstation-lswxl.dts

Signed-off-by: Roger Shimizu <rogershimizu@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gbp-Pq: Topic features/arm/device-tree
Gbp-Pq: Name ARM-dts-kirkwood-split-lswxl-dts-to-linkstation-lswsxl-an.patch

ARM: dts: kirkwood: relicense dts of ls-wvl/vl and ls-wxl/wsxl under GPLv2/X11

Signed-off-by: Roger Shimizu <rogershimizu@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gbp-Pq: Topic features/arm/device-tree
Gbp-Pq: Name ARM-dts-kirkwood-relicense-dts-of-ls-wvl-vl-and-ls-wxl-ws.patch

ARM: dts: orion5x: fix the missing mtd flash on linkstation lswtgl

MTD flash stores u-boot and u-boot environment on linkstation lswtgl.
The latter one can be easily read/write by u-boot-tools package in Debian.

Fixes: dc57844a736f ("ARM: dts: orion5x: add buffalo linkstation ls-wtgl")
Signed-off-by: Roger Shimizu <rogershimizu@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gbp-Pq: Topic features/arm/device-tree
Gbp-Pq: Name ARM-dts-orion5x-fix-missing-mtdflash-linkstation-lswtgl.patch

ARM: dts: orion5x: gpio pin fixes for linkstation lswtgl

Here're a few gpio pin related fixes:
  - remove pinctrl-0 definition from pinctrl, since those pins are used
    in other places such as gpio-fan and regulators.
  - keep initial state of power led
  - fix for alarm pin of gpio-fan.

Fixes: dc57844a736f ("ARM: dts: orion5x: add buffalo linkstation ls-wtgl")
Signed-off-by: Roger Shimizu <rogershimizu@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gbp-Pq: Topic features/arm/device-tree
Gbp-Pq: Name ARM-dts-orion5x-gpio-pin-fixes-for-linkstation-lswtgl.patch

ARM: dts: kirkwood: gpio-leds fixes for linkstation ls-wvl/vl

The GPIOs controlling the LEDs, listed below, are active high, not low:
  - gpio-leds: "lswvl:red:alarm" pin
  - gpio-leds: "lswvl:red:func" pin
  - gpio-leds: "lswvl:amber:info" pin
  - gpio-leds: "lswvl:blue:func" pin
  - gpio-leds: "lswvl:red:hdderr{0,1}" pin

Fixes: c43379e150aa ("ARM: dts: add buffalo linkstation ls-wvl/vl")
Signed-off-by: Roger Shimizu <rogershimizu@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gbp-Pq: Topic features/arm/device-tree
Gbp-Pq: Name ARM-dts-kirkwood-gpio-leds-fixes-for-linkstation-ls-wvl-v.patch

ARM: dts: kirkwood: gpio-leds fixes for linkstation ls-wxl/wsxl

The GPIOs controlling the LEDs, listed below, are active high, not low:
  - gpio-leds: "lswxl:blue:power" pin
  - gpio-leds: "lswxl:red:func" pin
  - gpio-leds: "lswxl:red:hdderr{0,1}" pin

Fixes: e54e4b1b622e ("ARM: dts: add buffalo linkstation ls-wxl/wsxl")
Signed-off-by: Roger Shimizu <rogershimizu@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gbp-Pq: Topic features/arm/device-tree
Gbp-Pq: Name ARM-dts-kirkwood-gpio-leds-fixes-for-linkstation-ls-wxl-w.patch

ARM: dts: kirkwood: gpio pin fixes for linkstation ls-wxl/wsxl

For kirkwood, gpio pins starts from 32 are in the 2nd bank, so it should be
converted to "gpio1 <pin minus 32>" in dts file.
e.g. gpio 40 should be "gpio1 8"

Besides, a few other pin fixes for ls-wxl/wsxl, to match with mpp pin
definition:
  - gpio-leds: "lswxl:blue:power" pin
  - gpio-leds: "lswxl:red:func" pin
  - gpio-leds: "lswxl:red:hdderr0" pin
  - gpio-leds: "lswxl:red:hdderr1" pin
  - gpio-fan:  low/high/alarm pin

The pin/bank issue was found when discussing Debian Bug #810894
  [https://bugs.debian.org/810894#47]

Fixes: e54e4b1b622e ("ARM: dts: add buffalo linkstation ls-wxl/wsxl")
Reported-by: Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org>
Signed-off-by: Roger Shimizu <rogershimizu@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gbp-Pq: Topic features/arm/device-tree
Gbp-Pq: Name ARM-dts-kirkwood-gpio-pin-fixes-for-linkstation-ls-wxl-ws.patch

ARM: dts: kirkwood: gpio pin fixes for linkstation ls-wvl/vl

For kirkwood, gpio pins starts from 32 are in the 2nd bank, so it should be
converted to "gpio1 <pin minus 32>" in dts file.
e.g. gpio 40 should be "gpio1 8"

The pin/bank issue was found when discussing Debian Bug #810894
  [https://bugs.debian.org/810894#47]

Fixes: c43379e150aa ("ARM: dts: add buffalo linkstation ls-wvl/vl")
Reported-by: Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org>
Signed-off-by: Roger Shimizu <rogershimizu@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gbp-Pq: Topic features/arm/device-tree
Gbp-Pq: Name ARM-dts-kirkwood-gpio-pin-fixes-for-linkstation-ls-wvl-vl.patch

ARM: dts: imx6dlq-wandboard-revb1.dts: use unique model id

Downstream packages like Debian flash-kernel use
/proc/device-tree/model
to determine which dtb file to install.

Hence each dts in the Linux kernel should provide a unique model
identifier.

Commit 8536239e371f ("ARM: dts: Restructure imx6qdl-wandboard.dtsi for new
rev C1 board.")' created new files imx6dl-wandboard-revb1.dts and
imx6q-wandboard-revb1.dts but used the same model identifier as in
imx6dl-wandboard.dts and imx6q-wandboard.dts.

This patch provides unique model identifiers for revision B1 of
the Wandboard Dual and Wandbaord Quad.

The patch leaves imx6dl-wandboard.dts and imx6q-wandboard.dts unchanged
because it is not foreseeable if the same dts will valid for future
board revisions or not. Furthermore we should avoid unnecessary
changes.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Gbp-Pq: Topic features/arm/device-tree
Gbp-Pq: Name ARM-dts-imx6dlq-wandboard-revb1.dts-use-unique-model-id.patch

ARM: orion5x: multiplatform support

The orion5x platform is now ready to be enabled for multiplatform
support, this patch does the switch over by modifying the Kconfig file,
the defconfig and removing the last mach/*.h header that becomes obsolete
with this.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gbp-Pq: Topic features/arm
Gbp-Pq: Name arm-orion5x-multiplatform-support.patch

ARM: orion5x: clean up mach/*.h headers

This is a simple move of all header files that are no longer
included by anything else from the include/mach directory
to the platform directory itself as preparation for
multiplatform support.

The mach/uncompress.h headers are left in place for now,
and are mildly modified to be independent of the other
headers. They will be removed entirely when ARCH_MULTIPLATFORM
gets enabled and they become obsolete.

Rather than updating the path names inside of the comments
of each header, I delete those comments to avoid having to
update them again, should they get moved or copied another
time.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gbp-Pq: Topic features/arm
Gbp-Pq: Name arm-orion5x-clean-up-mach-.h-headers.patch

ARM: orion: use SPARSE_IRQ everywhere

As a preparation for multiplatform support, this moves all the
code using plat-orion over to use sparse irq support, which is
enabled implicitly for multiplatform.

In particular, the hardcoded NR_IRQS macro gets replaced with
a machine specific one that is set in the machine descriptor
in order to set up a static mapping for all legacy interrupts.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gbp-Pq: Topic features/arm
Gbp-Pq: Name arm-orion-use-sparse_irq-everywhere.patch

ARM: orion: always use MULTI_IRQ_HANDLER

As a preparation for multiplatform support, this enables
the MULTI_IRQ_HANDLER code unconditionally on dove and
orion5x, and introduces the respective code on mv78xx0,
which did not have it so far. The classic entry-macro.S
files are removed as they are now obsolete.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
[bwh: Adjust to apply on top of 4.4]

Gbp-Pq: Topic features/arm
Gbp-Pq: Name arm-orion-always-use-multi_irq_handler.patch

ARM: orion: move watchdog setup to mach-orion5x

The watchdog device node is created in plat-orion/common.c
but depends on the bridge address that is platform specific,
so as a preparation for orion multiplatform support, we
move it out of the common code into orion5x and dove.

At the moment, dove does not use the watchdog, so I'm marking
the function as __maybe_unused for the moment. The compiler
will be able to compile out the device definition this way,
and we can easily add it later.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gbp-Pq: Topic features/arm
Gbp-Pq: Name arm-orion-move-watchdog-setup-to-mach-orion5x.patch

hwrng: n2 - Attach on T5/M5, T7/M7 SPARC CPUs

n2rng: Attach on T5/M5, T7/M7 SPARC CPUs

(space to tab fixes after variable names)

Signed-off-by: Anatoly Pugachev <matorola@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Gbp-Pq: Topic features/sparc
Gbp-Pq: Name hwrng-n2-attach-on-t5-m5-t7-m7-sparc-cpus.patch

ARM: bcm2835: Add the auxiliary clocks to the device tree.

These will be used for enabling UART1, SPI1, and SPI2.

Signed-off-by: Eric Anholt <eric@anholt.net>
Gbp-Pq: Topic features/arm/rpi
Gbp-Pq: Name arm-bcm2835-add-the-auxiliary-clocks-to-the-device-t.patch

ARM: bcm2835: Add devicetree for bcm2836 and Raspberry Pi 2 B

The Pi 2 B ends up like a Pi 1 B+, with the same peripherals and
pinout, but the CPU and memory layout changed to use the 2836.

Signed-off-by: Eric Anholt <eric@anholt.net>
Gbp-Pq: Topic features/arm/rpi
Gbp-Pq: Name arm-bcm2835-add-devicetree-for-bcm2836-and-raspberry.patch

ARM: bcm2835: Move the CPU/peripheral include out of common RPi DT.

For Raspberry Pi 2, we want to use the same general pin assignment
bits, but need to use bcm2836.dtsi for the CPU instead.

Signed-off-by: Eric Anholt <eric@anholt.net>
Gbp-Pq: Topic features/arm/rpi
Gbp-Pq: Name arm-bcm2835-move-the-cpu-peripheral-include-out-of-c.patch

ARM: bcm2835: Split the DT for peripherals from the DT for the CPU

The set of peripherals remained constant across bcm2835 (Raspberry Pi
1) and bcm2836 (Raspberry Pi 2), but the CPU was swapped out.  Split
the files so that we can include just peripheral setup in 2836.

Signed-off-by: Eric Anholt <eric@anholt.net>
Gbp-Pq: Topic features/arm/rpi
Gbp-Pq: Name arm-bcm2835-split-the-dt-for-peripherals-from-the-dt.patch

ARM: bcm2835: add rpi power domain driver

This patch adds support for several power domains on Raspberry Pi,
including USB (so it can be enabled even if the bootloader didn't do
it), and graphics.

This patch is the combined work of Eric Anholt (who wrote USB support
inside of the Raspberry Pi firmware driver, and wrote the non-USB
domain support) and Alexander Aring (who separated the original USB
work out from the firmware driver).

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Gbp-Pq: Topic features/arm/rpi
Gbp-Pq: Name arm-bcm2835-add-rpi-power-domain-driver.patch

dt-bindings: add rpi power domain driver bindings

This patch adds devicetree tree bindings for the Raspberry Pi power
domain driver.

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Gbp-Pq: Topic features/arm/rpi
Gbp-Pq: Name dt-bindings-add-rpi-power-domain-driver-bindings.patch

ARM: bcm2835: Define two new packets from the latest firmware.

These packets give us direct access to the firmware's power management
code, as opposed to GET/SET_POWER_STATE packets that only had a couple
of domains implemented.

Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Gbp-Pq: Topic features/arm/rpi
Gbp-Pq: Name arm-bcm2835-define-two-new-packets-from-the-latest-f.patch

ARM: bcm2835: Add Kconfig support for bcm2836

This should be a complete port of bcm2835 functionality to bcm2836
(Raspberry Pi 2).

Signed-off-by: Eric Anholt <eric@anholt.net>
Gbp-Pq: Topic features/arm/rpi
Gbp-Pq: Name arm-bcm2835-add-kconfig-support-for-bcm2836.patch

ARM: bcm2835: Add a compat string for bcm2836 machine probe

Supporting the 2836 requires using the new interrupt controller, which
we have support for.

Signed-off-by: Eric Anholt <eric@anholt.net>
Gbp-Pq: Topic features/arm/rpi
Gbp-Pq: Name arm-bcm2835-add-a-compat-string-for-bcm2836-machine-.patch

dt-bindings: Add root properties for Raspberry Pi 2

Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Rob Herring <robh@kernel.org>
Gbp-Pq: Topic features/arm/rpi
Gbp-Pq: Name dt-bindings-add-root-properties-for-raspberry-pi-2.patch

drm/vc4: fix an error code

"exec->exec_bo" is NULL at this point so this code returns success.  We
want to return -ENOMEM.

Fixes: d5b1a78a772f ('drm/vc4: Add support for drawing 3D frames.')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Gbp-Pq: Topic features/arm/rpi
Gbp-Pq: Name drm-vc4-fix-an-error-code.patch

drm/vc4: allocate enough memory in vc4_save_hang_state()

"state" is smaller than "kernel_state" so we end up corrupting memory.

Fixes: 214613656b51 ('drm/vc4: Add an interface for capturing the GPU state after a hang.')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Gbp-Pq: Topic features/arm/rpi
Gbp-Pq: Name drm-vc4-allocate-enough-memory-in-vc4_save_hang_stat.patch

drm/vc4: copy_to_user() returns the number of bytes remaining

The copy_to/from_user() functions return the number of bytes remaining
to be copied.  We want to return error codes here.

Also it's a bad idea to print an error message if a copy from user fails
because users can use that to spam /var/log/messages which is annoying
so I removed those.

Fixes: 214613656b51 ('drm/vc4: Add an interface for capturing the GPU state after a hang.')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Gbp-Pq: Topic features/arm/rpi
Gbp-Pq: Name drm-vc4-copy_to_user-returns-the-number-of-bytes-rem.patch

drm/vc4: Add an interface for capturing the GPU state after a hang.

This can be parsed with vc4-gpu-tools tools for trying to figure out
what was going on.

v2: Use __u32-style types.

Signed-off-by: Eric Anholt <eric@anholt.net>
Gbp-Pq: Topic features/arm/rpi
Gbp-Pq: Name drm-vc4-add-an-interface-for-capturing-the-gpu-state.patch

drm/vc4: Add support for async pageflips.

An async pageflip stores the modeset to be done and executes it once
the BOs are ready to be displayed.  This gets us about 3x performance
in full screen rendering with pageflipping.

Signed-off-by: Eric Anholt <eric@anholt.net>
Gbp-Pq: Topic features/arm/rpi
Gbp-Pq: Name drm-vc4-add-support-for-async-pageflips.patch

drm/vc4: Add support for drawing 3D frames.

The user submission is basically a pointer to a command list and a
pointer to uniforms.  We copy those in to the kernel, validate and
relocate them, and store the result in a GPU BO which we queue for
execution.

v2: Drop support for NV shader recs (not necessary for GL), simplify
    vc4_use_bo(), improve bin flush/semaphore checks, use __u32 style
    types.

Signed-off-by: Eric Anholt <eric@anholt.net>
Gbp-Pq: Topic features/arm/rpi
Gbp-Pq: Name drm-vc4-add-support-for-drawing-3d-frames.patch

drm/vc4: Bind and initialize the V3D engine.

This is the component of the GPU that does 3D rendering.

Signed-off-by: Eric Anholt <eric@anholt.net>
Gbp-Pq: Topic features/arm/rpi
Gbp-Pq: Name drm-vc4-bind-and-initialize-the-v3d-engine.patch

drm/vc4: Fix a typo in a V3D debug register.

Signed-off-by: Eric Anholt <eric@anholt.net>
Gbp-Pq: Topic features/arm/rpi
Gbp-Pq: Name drm-vc4-fix-a-typo-in-a-v3d-debug-register.patch

drm/vc4: Add an API for creating GPU shaders in GEM BOs.

Since we have no MMU, the kernel needs to validate that the submitted
shader code won't make any accesses to memory that the user doesn't
control, which involves banning some operations (general purpose DMA
writes), and tracking where we need to write out pointers for other
operations (texture sampling).  Once it's validated, we return a GEM
BO containing the shader, which doesn't allow mapping for write or
exporting to other subsystems.

v2: Use __u32-style types.

Signed-off-by: Eric Anholt <eric@anholt.net>
Gbp-Pq: Topic features/arm/rpi
Gbp-Pq: Name drm-vc4-add-an-api-for-creating-gpu-shaders-in-gem-b.patch

drm/vc4: Add create and map BO ioctls.

While there exist dumb APIs for creating and mapping BOs, one of the
rules is that drivers doing 3D acceleration have to provide their own
APIs for buffer allocation (besides, the pitch/height parameters of
the dumb alloc don't really make sense for a lot of 3D allocations).

v2: Use __u32-style types, use "drm.h" instead of <drm/drm.h>.

Signed-off-by: Eric Anholt <eric@anholt.net>
Gbp-Pq: Topic features/arm/rpi
Gbp-Pq: Name drm-vc4-add-create-and-map-bo-ioctls.patch

drm/vc4: Add a BO cache.

We need to allocate new BOs in the kernel as part of each frame, but
the CMA allocator is way too slow for that.  As an optimization, keep
track of recently-freed BOs and reuse them, with a 1 second timeout to
fully free them back to the system.

This improves 3D performance by about 15%.

Signed-off-by: Eric Anholt <eric@anholt.net>
Gbp-Pq: Topic features/arm/rpi
Gbp-Pq: Name drm-vc4-add-a-bo-cache.patch

drm: Create a driver hook for allocating GEM object structs.

The CMA helpers had no way for a driver to extend the struct with its
own fields.  Since the CMA helpers are mostly "Allocate a
drm_gem_cma_object, then fill in a few fields", it's hard to write as
pure helpers without passing in a driver callback for the allocate
step.

Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Gbp-Pq: Topic features/arm/rpi
Gbp-Pq: Name drm-create-a-driver-hook-for-allocating-gem-object-s.patch

pwm: bcm2835: Fix email address specification

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Gbp-Pq: Topic features/arm/rpi
Gbp-Pq: Name pwm-bcm2835-fix-email-address-specification.patch

pwm: bcm2835: Prevent division by zero

It's possible that the PWM clock becomes an orphan. So better check the
result of clk_get_rate() in order to prevent a division by zero.

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Gbp-Pq: Topic features/arm/rpi
Gbp-Pq: Name pwm-bcm2835-prevent-division-by-zero.patch

pwm: bcm2835: Calculate scaler in ->config()

Currently pwm-bcm2835 assumes a fixed clock rate and stores the
resulting scaler in the driver structure. But with the upcoming
PWM clock support for clk-bcm2835 the rate could change, so
calculate the scaler in the ->config() callback.

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Gbp-Pq: Topic features/arm/rpi
Gbp-Pq: Name pwm-bcm2835-calculate-scaler-in-config.patch

x86: Make x32 syscall support conditional on a kernel parameter

Enabling x32 in the standard amd64 kernel would increase its attack
surface while provide no benefit to the vast majority of its users.
No-one seems interested in regularly checking for vulnerabilities
specific to x32 (at least no-one with a white hat).

Still, adding another flavour just to turn on x32 seems wasteful.  And
the only differences on syscall entry are two instructions (mask out
the x32 flag and compare the syscall number).

So pad the standard comparison with a nop and add a kernel parameter
"syscall.x32" which controls whether this is replaced with the x32
version at boot time.  Add a Kconfig parameter to set the default.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name x86-make-x32-syscall-support-conditional.patch

x86: memtest: WARN if bad RAM found

Since this is not a particularly thorough test, if we find any bad
bits of RAM then there is a fair chance that there are other bad bits
we fail to detect.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name x86-memtest-WARN-if-bad-RAM-found.patch

MIPS: octeon: Add support for the UBNT E200 board

Add support for the UBNT E200 board (EdgeRouter/EdgeRouter Pro 8 port).

Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
[bwh: Forward-ported to 3.17: adjust context]

Gbp-Pq: Topic features/mips
Gbp-Pq: Name MIPS-octeon-Add-support-for-the-UBNT-E200-board.patch

MIPS: Loongson 3: Add Loongson LS3A RS780E 1-way machine definition

Add a Loongson LS3A RS780E 1-way machine definition, which only differs
from other Loongson 3 based machines by the UART base clock speed.

Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
[bwh: Forward-ported to 4.2]

Gbp-Pq: Topic features/mips
Gbp-Pq: Name MIPS-Loongson-3-Add-Loongson-LS3A-RS780E-1-way-machi.patch

MIPS: increase MAX_PHYSMEM_BITS on Loongson 3 only

Commit c4617318 broke Loongson-2 support and maybe even more by increasing
the value of MAX_PHYSMEM_BITS. At it is currently only needed on
Loongson-3, define it conditionally.

Note: this should be replace by upstream fix when available.

Gbp-Pq: Topic features/mips
Gbp-Pq: Name MIPS-increase-MAX-PHYSMEM-BITS-on-Loongson-3-only.patch

MIPS: math-emu: Correctly handle NOP emulation

Fix an issue introduced with commit 9ab4471c9f1b ("MIPS: math-emu:
Correct delay-slot exception propagation") where the emulation of a NOP
instruction signals the need to terminate the emulation loop.  This in
turn, if the PC has not changed from the entry to the loop, will cause
the kernel to terminate the program with SIGILL.

Consider this program:

static double div(double d)
{
do
d /= 2.0;
while (d > .5);
return d;
}

int main(int argc, char **argv)
{
return div(argc);
}

which gets compiled to the following binary code:

00400490 <main>:
  400490: 44840000  mtc1 a0,$f0
  400494: 3c020040  lui v0,0x40
  400498: d44207f8  ldc1 $f2,2040(v0)
  40049c: 46800021  cvt.d.w $f0,$f0
  4004a0: 46220002  mul.d $f0,$f0,$f2
  4004a4: 4620103c  c.lt.d $f2,$f0
  4004a8: 4501fffd  bc1t 4004a0 <main+0x10>
  4004ac: 00000000  nop
  4004b0: 4620000d  trunc.w.d $f0,$f0
  4004b4: 03e00008  jr ra
  4004b8: 44020000  mfc1 v0,$f0
  4004bc: 00000000  nop

Where the FPU emulator is used, depending on the number of command-line
arguments this code will either run to completion or terminate with
SIGILL.

If no arguments are specified, then BC1T will not be taken, NOP will not
be emulated and code will complete successfully.

If one argument is specified, then BC1T will be taken once and NOP will
be emulated.  At this point the entry PC value will be 0x400498 and the
new PC value, set by `mips_dsemul' will be 0x4004a0, the target of BC1T.
The emulation loop will terminate, but SIGILL will not be issued,
because the PC has changed.  The FPU emulator will be entered again and
on the second execution BC1T will not be taken, NOP will not be emulated
and code will complete successfully.

If two or more arguments are specified, then the first execution of BC1T
will proceed as above.  Upon reentering the FPU emulator the emulation
loop will continue to BC1T, at which point the branch will be taken and
NOP emulated again.  At this point however the entry PC value will be
0x4004a0, the same as the target of BC1T.  This will make the emulator
conclude that execution has not advanced and therefore an unsupported
FPU instruction has been encountered, and SIGILL will be sent to the
process.

Fix the problem by extending the internal API of `mips_dsemul', making
it return -1 if no delay slot emulation frame has been made, the
instruction has been handled and execution of the emulation loop needs
to continue as if nothing happened.  Remove code from `mips_dsemul' to
reproduce steps made by the emulation loop at the conclusion of each
iteration, as those will be reached normally now.  Adjust call sites
accordingly.  Document the API.

Signed-off-by: Maciej W. Rozycki <macro@imgtec.com>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12172/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Gbp-Pq: Topic bugfix/mips
Gbp-Pq: Name mips-math-emu-correctly-handle-nop-emulation.patch

viafb: Autoload on OLPC XO 1.5 only

It appears that viafb won't work automatically on all the boards for
which it has a PCI device ID match.  Currently, it is blacklisted by
udev along with most other framebuffer drivers, so this doesn't matter
much.

However, this driver is required for console support on the XO 1.5.
We need to allow it to be autoloaded on this model only, and then
un-blacklist it in udev.

Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name viafb-autoload-on-olpc-xo1.5-only.patch

snd-pcsp: Disable autoload

There are two drivers claiming the platform:pcspkr device:
- pcspkr creates an input(!) device that can only beep
- snd-pcsp creates an equivalent input device plus a PCM device that can
  play barely recognisable renditions of sampled sound

snd-pcsp is blacklisted by the alsa-base package, but not everyone
installs that.  On PCs where no sound is wanted at all, both drivers
will still be loaded and one or other will complain that it couldn't
claim the relevant I/O range.

In case anyone finds snd-pcsp useful, we continue to build it.  But
remove the alias, to ensure it's not loaded where it's not wanted.

Gbp-Pq: Topic debian
Gbp-Pq: Name snd-pcsp-disable-autoload.patch

cdc_ncm,cdc_mbim: Use NCM by default

Devices that support both NCM and MBIM modes should be kept in NCM
mode unless there is userland support for MBIM.

Set the default value of cdc_ncm.prefer_mbim to false and leave it to
userland (modem-manager) to override this with a modprobe.conf file
once it's ready to speak MBIM.

Gbp-Pq: Topic debian
Gbp-Pq: Name cdc_ncm-cdc_mbim-use-ncm-by-default.patch

add sysctl to disallow unprivileged CLONE_NEWUSER by default

add sysctl to disallow unprivileged CLONE_NEWUSER by default

This is a short-term patch.  Unprivileged use of CLONE_NEWUSER
is certainly an intended feature of user namespaces.  However
for at least saucy we want to make sure that, if any security
issues are found, we have a fail-safe.

Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
[bwh: Remove unneeded binary sysctl bits]

Gbp-Pq: Topic debian
Gbp-Pq: Name add-sysctl-to-disallow-unprivileged-CLONE_NEWUSER-by-default.patch

yama: Disable by default

Gbp-Pq: Topic debian
Gbp-Pq: Name yama-disable-by-default.patch

cgroups: Document the Debian memory resource controller config change

Gbp-Pq: Topic debian
Gbp-Pq: Name cgroups-Document-the-Debian-memory-resource-controll.patch

cgroups: Allow memory cgroup support to be included but disabled

Memory cgroup support has some run-time overhead, so it's useful to
include it in a distribution kernel without enabling it by default.
Add a kernel config option to disable it by default and a kernel
parameter 'cgroup_enable' as the opposite to 'cgroup_disable'.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[Bastian Blank: Rename CGROUP_MEM_RES_CTLR_DISABLED to MEMCG_DISABLED]

Gbp-Pq: Topic features/all
Gbp-Pq: Name cgroups-Allow-memory-cgroup-support-to-be-included-b.patch

sched: Do not enable autogrouping by default

We want to provide the option of autogrouping but without enabling
it by default yet.

Gbp-Pq: Topic debian
Gbp-Pq: Name sched-autogroup-disabled.patch

fs: Enable link security restrictions by default

This reverts commit 561ec64ae67ef25cac8d72bb9c4bfc955edfd415
('VFS: don't do protected {sym,hard}links by default').

Gbp-Pq: Topic debian
Gbp-Pq: Name fs-enable-link-security-restrictions-by-default.patch

decnet: Disable auto-loading as mitigation against local exploits

Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation.  We can mitigate the effect of any
remaining vulnerabilities in such protocols by preventing unprivileged
users from loading the modules, so that they are only exploitable on
systems where the administrator has chosen to load the protocol.

The 'decnet' protocol is unmaintained and of mostly historical
interest, and the user-space support package 'dnet-common' loads the
module explicitly.  Therefore disable auto-loading.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name decnet-Disable-auto-loading-as-mitigation-against-lo.patch

rds: Disable auto-loading as mitigation against local exploits

Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation.  We can mitigate the effect of any
remaining vulnerabilities in such protocols by preventing unprivileged
users from loading the modules, so that they are only exploitable on
systems where the administrator has chosen to load the protocol.

The 'rds' protocol is one such protocol that has been found to be
vulnerable, and which was not present in the 'lenny' kernel.
Therefore disable auto-loading.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name rds-Disable-auto-loading-as-mitigation-against-local.patch

af_802154: Disable auto-loading as mitigation against local exploits

Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation.  We can mitigate the effect of any
remaining vulnerabilities in such protocols by preventing unprivileged
users from loading the modules, so that they are only exploitable on
systems where the administrator has chosen to load the protocol.

The 'af_802154' (IEEE 802.15.4) protocol is not widely used, was
not present in the 'lenny' kernel, and seems to receive only sporadic
maintenance.  Therefore disable auto-loading.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name af_802154-Disable-auto-loading-as-mitigation-against.patch

aufs4.x-rcN standalone patch

Patch headers added by debian/patches/features/all/aufs4/gen-patch

aufs4.x-rcN standalone patch

Gbp-Pq: Topic features/all/aufs4
Gbp-Pq: Name aufs4-standalone.patch